스프린트(Sprint)는 애자일 개발 방법론의 핵심입니다. 2주 단위로 작업을 계획하고 실행하며, 지속적으로 개선하는 사이클을 만듭니다. 이 글에서는 실제 프로젝트에서 사용한 스프린트 운영 가이드를 정리했습니다.

작업 티켓 단위별 발행 담당자

프로젝트 작업을 체계적으로 관리하기 위해 티켓을 계층적으로 구성합니다. 각 티켓 단위별로 담당자가 명확히 정해져 있습니다.

구분 담당 프로젝트 상세
Epic PM 프로젝트 에픽 티켓 생성
Story PM 기획서 내 사용자 스토리 기반으로 스토리 티켓 생성
Task 담당 개발자 & 디자이너 각 담당 개발자&디자이너가 프로젝트 스토리 달성을 위한 테스크 티켓 생성
SubTask 각자 관리 스프린트에서 관리되지 않아도 되는 작업 단위를 생성하여 관리

스프린트 운영 프로세스

스프린트는 크게 3단계로 구성됩니다. 각 단계별로 명확한 역할과 책임이 정해져 있어 프로젝트가 체계적으로 진행됩니다.

1단계: 기획 리뷰

  • (PM) 기획 리뷰 진행
  • 리뷰 대상자: 서버 개발자, 프론트 개발자, 디자이너, QA
  • (PM) 첫 스토리 티켓 생성: 기획서의 사용자 시나리오를 기반으로 스토리 티켓을 생성합니다

2단계: 스펙 조정 및 작업 계획 (기획 리뷰 후 1주일)

  • (PM) 스펙 조정 및 기획 재반영: 1단계에서 나온 피드백을 반영하여 기획을 조정합니다
  • (PM) 스토리 티켓 수정: 변경된 기획 내용을 반영하여 스토리 티켓을 업데이트합니다
  • (각 개발 담당자) 스토리 티켓 업데이트:
    • 스토리 티켓 라벨 기재
    • 각 영역별 작업이 필요 없는 경우, 지라 티켓 코멘트로 "검토 완료, 작업 불필요" 코멘트 남기기
    • Story 하위의 Task 티켓 생성
  • 각 개발 담당자 대략적인 공수 산정

3단계: 스프린트 실행

스프린트 플래닝 (2주 단위)

  • 2주 단위 수요일마다 플래닝, 화요일 배포
  • 스프린트 플래닝 미팅 전 다음 스프린트 작업 항목 리스팅
  • 이번 스프린트에 배포할 작업 사항 확정
  • 플래닝 시작 전 아이스브레이킹 타임 갖기 (이때, 지난 스프린트 소회 나누기)

스탠드업

  • 상시 이슈 공유 및 해소, 작업 조율
  • 배포 일정 내 배포 불가한 사항들은 즉시 공유하기
  • 다른 프로젝트와 충돌하여 이슈가 생기는 경우 즉시 공유하기

스프린트 일정표

다음은 3주 단위 스프린트 일정표 예시입니다. 스프린트1과 스프린트2가 겹치면서 진행되는 구조입니다.

주차
1주차 스프린트1 플래닝 스프린트2 기획 리뷰 기간 스프린트2 기획 리뷰 기간스프린트2 기획 리뷰 작업 항목 공수 산정
2주차 스프린트2 기획 리뷰 기간스프린트2 기획 리뷰 작업 항목 공수 산정 스프린트2 기획 리뷰 기간스프린트2 기획 리뷰 작업 항목 공수 산정 스프린트2 기획 리뷰 작업 항목 공수 산정 스프린트2 기획 리뷰 작업 항목 공수 산정 스프린트2 기획 리뷰 작업 항목 공수 산정
3주차 스프린트2 기획 리뷰 작업 항목 공수 산정 스프린트1 운영 배포스프린트2 작업 항목 리스팅 스프린트2 플래닝

스프린트 운영 원칙

유연한 일정 관리

  • 대략적인 일정을 제시하고, 매 스프린트마다 검토하면서 조정해 나갑니다
  • 스프린트 진행 중 작업이 예상보다 크다면 즉시 공유하고 다음 스프린트로 미룹니다
  • 작업 분석 기간을 충분히 확보합니다

테트리스 방식의 플래닝

스프린트 플래닝은 마치 테트리스를 하는 것과 같습니다:

  • P1: 작업 스프린트(수요일) + P2: 작업 파악 스프린트(목요일)
  • 다음 스프린트에서 P2 작업을 수행하면서 동시에 P3 작업을 파악하는 스프린트 진행

이렇게 하면 현재 스프린트를 실행하면서 동시에 다음 스프린트를 준비할 수 있어 효율적입니다.

마무리

스프린트는 단순히 작업을 나누는 것이 아니라, 팀의 협업과 소통을 강화하는 프로세스입니다. 명확한 역할 분담과 정기적인 플래닝, 그리고 지속적인 소통을 통해 프로젝트를 성공적으로 완료할 수 있습니다.

가장 중요한 것은 유연성입니다. 계획대로 진행되지 않을 때도 있지만, 이를 즉시 공유하고 조정하는 것이 스프린트의 핵심입니다.